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An Acceptable Use Policy for New ICMP Types and Codes 
Abstract 


In this document we provide a basic description of ICMP's role in the 
IP stack and some guidelines for future use. 


This document is motivated by concerns about lack of clarity 
concerning when to add new Internet Control Message Protocol (ICMP) 
types and/or codes. These concerns have highlighted a need to 
describe policies for when adding new features to ICMP is desirable 
and when it is not. 

Status of This Memo 


This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http: //www.rfc-editor.org/info/rfc7279. 


Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


There has been some recent concern expressed about a lack of clarity 
around when new message types and codes should be added to ICMP 
(including ICMPv4 [RFC0792] and ICMPv6 [RFC4443]). We lay out a 
policy regarding when (and when not) to move functionality into ICMP. 


This document is the result of discussions among ICMP experts within 
the Operations and Management (OPS) area’s IP Diagnostics Technical 

Interest Group [DIAGNOSTICS] and concerns expressed by the OPS area 

leadership. 


Note that this document does not supercede the "IANA Allocation 
Guidelines For Values In the Internet Protocol and Related Headers" 
[RFC2780], which specifies best practices and processes for the 
allocation of values in the IANA registries but does not describe the 
policies to be applied in the standards process. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Acceptable Use Policy 
In this document, we describe an acceptable use policy for new ICMP 


message types and codes, and provide some background about the 
policy. 
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In summary, any future message types added to ICMP should be limited 
to two broad categories: 


T; 


to inform a datagram's originator that a forwarding plane anomaly 
has been encountered downstream. The datagram originator must be 
able to determine whether or not the datagram was discarded by 
examining the ICMP message. 


to discover and convey dynamic information about a node (other 
than information usually carried in routing protocols), to 
discover and convey network-specific parameters, and to discover 
on-link routers and hosts. 


Normally, ICMP SHOULD NOT be used to implement a general-purpose 


rout 


ing or network management protocol. However, ICMP does have a 


role to play in conveying dynamic information about a network, which 


would belong in category 2 above. 
2.1. Classification of Existing Message Types 
This section provides a rough breakdown of existing message types 
according to the taxonomy described in Section 2 at the time of 
publication. 
IPv4 forwarding plane anomaly reporting: 
35 Destination Unreachable 
4: Source Quench (Deprecated) 
6: Alternate Host Address (Deprecated) 
11: Time Exceeded 
12: Parameter Problem 
31: Datagram Conversion Error (Deprecated) 
IPv4 router or host discovery: 
O: Echo Reply 
g; Redirect 
8: Echo 
94 Router Advertisement 
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10: Router Solicitation 

13: Timestamp 

14: Timestamp Reply 

15: Information Request (Deprecated) 
16: Information Reply (Deprecated) 
17: Address Mask Request (Deprecated) 


18: Address Mask Reply (Deprecated) 


30: Traceroute (Deprecated) 

32: Mobile Host Redirect (Deprecated) 

33: IPv6 Where-Are-You (Deprecated) 

34: IPv6 I-Am-Here (Deprecated) 

35: Mobile Registration Request (Deprecated) 
36: Mobile Registration Reply (Deprecated) 
37: Domain Name Request (Deprecated) 

38: Domain Name Reply (Deprecated) 

39: SKIP (Deprecated) 

40: Photuris 


41: ICMP messages utilized by experimental mobility protocols 
such as Seamoby 


Please note that some ICMP message types were formally deprecated by 
[RFC6918]. 


IPv6 forwarding plane anomaly reporting: 
12 Destination Unreachable 


23 Packet Too Big 
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35 Time Exceeded 
4: Parameter Problem 


150: ICMP messages utilized by experimental mobility protocols 
such as Seamoby 


IPv6 router or host discovery: 
128: Echo Request 
129: Echo Reply 
130: Multicast Listener Query 
131: Multicast Listener Report 
132: Multicast Listener Done 
133: Router Solicitation 
134: Router Advertisement 
135: Neighbor Solicitation 
136: Neighbor Advertisement 
137: Redirect Message 
138: Router Renumbering 
139: ICMP Node Information Query 
140: ICMP Node Information Response 
141: Inverse Neighbor Discovery Solicitation Message 
142: Inverse Neighbor Discovery Advertisement Message 
143: Version 2 Multicast Listener Report 
144: Home Agent Address Discovery Request Message 
145: Home Agent Address Discovery Reply Message 


146: Mobile Prefix Solicitation 
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147: Mobile Prefix Advertisement 
148: Certification Path Solicitation Message 
149: Certification Path Advertisement Message 


150: ICMP messages utilized by experimental mobility protocols 
such as Seamoby 


151: Multicast Router Advertisement 
152: Multicast Router Solicitation 
153: Multicast Router Termination 
154: FMIPv6 Messages 
155: RPL Control Message 

2.1.1. ICMP Use as a Routing Protocol 


As mentioned in Section 2, using ICMP as a general-purpose routing or 
network management protocol is not advisable and SHOULD NOT be used 
that way. 


ICMP has a role in the Internet as an integral part of the IP layer; 
it is not as a routing protocol or as a transport protocol for other 
layers including routing information. From a more pragmatic 
perspective, some of the key characteristics of ICMP make it a less- 
than-ideal choice for a routing protocol. These key characteristics 
include that ICMP is frequently filtered, is not authenticated, and 
is easily spoofed. In addition, specialist hardware processing of 
ICMP would disrupt the deployment of an ICMP-based routing or 
management protocol. 


2.1.2. A Few Notes on RPL 


RPL, the IPv6 routing protocol for low-power and lossy networks (see 
[RFC6550]) uses ICMP as a transport. In this regard, it is an 
exception among the ICMP message types. Note that, although RPL is 
an IP routing protocol, it is not deployed on the general Internet; 
it is limited to specific, contained networks. 


This should be considered anomalous and is not a model for future 
ICMP message types. That is, ICMP is not intended as a transport for 
other protocols and SHOULD NOT be used in that way in future 
specifications. In particular, while it is adequate to use ICMP as a 
discovery protocol, it does not extend to full routing capabilities. 
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2.2. Applications Using ICMP 


Some applications make use of ICMP error notifications, or even 
deliberately create anomalous conditions in order to elicit ICMP 
messages. These ICMP messages are then used to generate feedback to 
the higher layer. Some of these applications include some of the 
most widespread examples, such as PING, TRACEROUTE, and Path MIU 
Discovery (PMTUD). These uses are considered acceptable because they 
use existing ICMP message types and do not change ICMP functionality. 


2.3. Extending ICMP 


ICMP multi-part messages are specified in [RFC4884] by defining an 
extension mechanism for selected ICMP messages. This mechanism 
addresses a fundamental problem in ICMP extensibility. An ICMP 
multi-part message carries all of the information that ICMP messages 
carried previously, as well as additional information that 
applications may require. 


Some currently defined ICMP extensions include ICMP extensions for 
Multiprotocol Label Switching [RFC4950] and ICMP extensions for 
interface and next-hop identification [RFC5837]. 


Extensions to ICMP SHOULD follow the requirements provided in 
[RFC4884]. 


2.4. ICMPv4 vs. ICMPV6 


Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6 
routers, IPv6-capable security gateways, and IPv6-capable firewalls 
normally support administrator configuration of how specific ICMPv6 
message types are handled. By contrast, deployed IPv4 routers, 
IPv4-capable security gateways, and IPv4-capable firewalls are less 
likely to allow an administrator to configure how specific ICMPv4 
message types are handled. So, at present, ICMPv6 messages usually 
have a higher probability of travelling end-to-end than ICMPv4 
messages. 


3. ICMP's Role in the Internet 


ICMP was originally intended to be a mechanism for gateways or 

destination hosts to report error conditions back to source hosts in 
ICMPv4 [RFC0792]; ICMPv6 [RFC4443] is modeled after it. ICMP is also 
used to perform IP-layer functions, such as diagnostics (e.g., PING). 


ICMP is defined to be an integral part of IP and must be implemented 


by every IP module. This is true for ICMPv4 as an integral part of 
IPv4 (see the Introduction of [RFCO792]), and for ICMPv6 as an 
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6. 


6. 


integral part of IPv6 (see Section 2 of [RFC4443]). When first 
defined, ICMP messages were thought of as IP messages that didn't 
carry any higher-layer data. It could be conjectured that the term 
"control" was used because ICMP messages were not "data" messages. 


The word "control" in the protocol name did not describe ICMP’s 
function (i.e., it did not "control" the Internet); rather, it was 
used to communicate about the control functions in the Internet. For 
example, even though ICMP included a redirect message type that 
affects routing behavior in the context of a LAN segment, it was not 
and is not used as a generic routing protocol. 


Security Considerations 


This document describes a high-level policy for adding ICMP types and 
codes. While special attention must be paid to the security 
implications of any particular new ICMP type or code, this 
recommendation presents no new security considerations. 


From a security perspective, ICMP plays a part in the Photuris 
protocol [RFC2521]. But more generally, ICMP is not a secure 
protocol and does not include features to be used to discover network 
security parameters or to report on network security anomalies in the 
forwarding plane. 


Additionally, new ICMP functionality (e.g., ICMP extensions, or new 
ICMP types or codes) needs to consider potential ways that ICMP can 
be abused (e.g., Smurf IP DoS [CA-1998-01]). 
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